home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20010921-20020314
/
000111_belal@caldera.com_Sun Nov 4 19:37:03 EST 2001.msg
< prev
next >
Wrap
Text File
|
2002-03-13
|
5KB
|
95 lines
Article: 12929 of comp.protocols.kermit.misc
Newsgroups: comp.unix.sco.misc,comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!fu-berlin.de!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!feedwest.news.agis.net!us.telia.net!news.mainstreet.net!feeder.nmix.net!feeder.swcp.com!192.75.213.3.MISMATCH!enigma.xenitec.on.ca!news.xenitec.on.ca!news
From: Bela Lubkin <belal@caldera.com>
Subject: Re: Dropping DTR in OSR5
Resent-From: mmdf@xenitec.on.ca
Submit-To: scomsc@xenitec.on.ca
Content-Type: text/plain; charset=us-ascii
Organization: [resent by] The SCOMSC gateway and Propagation Society
Content-Disposition: inline
Date: Mon, 5 Nov 2001 00:09:17 GMT
Message-ID: <20011104160917.A13779@mammoth.ca.caldera.com>
User-Agent: Mutt/1.2.5i
To: scomsc@xenitec.on.ca
Mime-Version: 1.0
In-Reply-To: <3be5c667$0$439$8eec23a@newsreader.tycho.net>; from spcecdt@deepthought.armory.com on Sun, Nov 04, 2001 at 10:51:20PM +0000
References: <9s40rp$fdh$1@newsmaster.cc.columbia.edu> <3be5c667$0$439$8eec23a@newsreader.tycho.net>
Sender: belal@caldera.com
Precedence: list
Lines: 72
Xref: newsmaster.cc.columbia.edu comp.unix.sco.misc:139886 comp.protocols.kermit.misc:12929
John DuBois wrote:
> In article <9s40rp$fdh$1@newsmaster.cc.columbia.edu>,
> Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
> >But the real problem is that when Kermit *does* try to drop DTR briefly,
> >it never comes back on. So I need to ask: What is the way to turn off
> >DTR and then turn it back on in OSR5? Currently I am using the POSIX
> >way:
> >
> > cfgetospeed() and cfgetispeed() to get the speeds.
> > cfsetospeed() and cfsetispeed() to set the speed to 0.
> > tcsetattr() to make the speed changes take effect.
> > (pause)
> > cfsetospeed() and cfsetispeed() to restore the original speeds.
> > tcsetattr() to make the speed changes take effect.
> >
> >The same code works fine on Linux, FreeBSD, and other platforms that use
> >POSIX APIs. It appears to work fine in OSR5 too: the steps before the
> >pause actually do work. But the steps after the pause, although they
> >return no error indication and do not set errno, do not in fact make DTR
> >and RTS come back on (as shown by the modem lights and the failure of the
> >modem to respond to further commands).
>
> Some problems in this area were fixed in 5.0.6a. Please test on that release
> and see if you still encounter this problem.
While this is true, Frank likes to support every OS ever made. I
believe he still builds binaries for SCO Xenix. A solution which
requires users to have an OS less than a year old won't satisfy him...
The OpenServer "sio" driver doesn't implement ispeed and ospeed as
separate entities. The functions exist and the structures have all the
necessary members, but it doesn't pay attention to the input rate, only
the output rate. At least, that's how it's _intended_ to work. I
vaguely remember that you can get into trouble -- confuse the driver --
by trying to change both. This might have been one of the things fixed
in rs506a. But I think the problem can be avoided on all releases, by
only programming the output speed.
So, suppose you test with only changing ospeed, see whether that makes a
difference?
This also isn't a general solution. There are third party drivers that
slot into the same ioctls, but _do_ correctly support independent i/o
speeds. Does Kermit have any system-specific hint settings? Something
like an OpenServer-specific "set ignore-ospeed", turned on by default?
"On" is the correct default since "sio" is the most common serial driver
on OpenServer, and split-speed usage is rather uncommon.
And, if I'm wrong, you might try an even kludgier workaround (which also
might not work, but is definitely worth trying): after having performed
all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
your pseudo-code above, force an extra open of the port:
...
tcsetattr()
if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
close(kludge_fd);
I'm pretty sure this will cause "sio" to get its house in order and
raise DTR (and the close shouldn't lower it, since the other open still
exists). For debugging purposes you might need to put in a pause before
the close() to observe that DTR actually goes on -- I don't fully trust
my assertion that the close() won't lower it.
One last thing. There's a comment in the driver that implies that after
cycling the baud rate through 0, DTR might not come back up immediately;
might only come up when you output a character. I'm pretty sure this is
fixed in rs506a, but for older releases, see whether outputting a NUL
after the 2nd tcsetattr() causes DTR to wake up.
>Bela<